## 질문

나는 현재 사용자(user)가 변호사인 a full vertical legal AI Agent를 개발 중이다. 이 에이전트는 대한민국 민사소송에서 원고를 대리하는 변호사가 사용자인 경우를 다루는 법률 인공지능 에이전트다. 사용자가 고객상담문서(client_meeting.md)와 모든 증거문서(서증)들을 정보화한 JSON 문서(evidence_all.json)을 업로드하면 에이전트는 1단계부터 5단계까지 작업을 순차적으로 진행하여 최종적으로 소장(complaint)을 생성한다. 사용자가 고객상담문서(client_meeting.md)와 모든 증거문서(서증)들을 정보화한 JSON 문서(evidence_all.json)을 이미 업로드했음을 가정한다. Stage 1에서 에이전트는 현재 다루고 있는 사건의 개요를 상세하게 파악한다. 에이전트는 `1. Stage 1` 폴더의 Stage_1_new_updated_v3.yaml을 실행하여 결과물을 생성한다. 생성한 결과물들은 `1. Stage 1/outpus` 폴더에 저장되어 있다:
- actio_case_signals.json
- BO.json
- client_goal.json
- evidence_actio_support.json
- evidence_event_candidates.json
- evidence_indexed.json
- fact_actio_support.json
- Fact_Ledger_base.json

Stage 2에서 에이전트는 1단계 결과물들을 입력받아 소송 청구권들을 식별하고 그 청구권들의 사건 종류를 결정한다. 에이전트는 `2. Stage 2`폴더의 Stage_2_updated_A_B_C_v6.yml을 실행하여 결과물을 생성하며, 생성한 결과물들은 `2. Stage 2/outputs` 폴더에 저장되어 있다:
- claim_identification_view.json
- claims_identified_case_type.json
- claims_identified.json

이제 Stage 2의 Task_D와 Task_E 작업을 수행할 프롬프트를 작성하려고 한다. Task_E는 식별된 청구권들에 대해서 소장(complaint)에 기입할 '청구취지'와 '청구원인'을 최대한 자세히 작성하는 것을 목표로 한다. 이를 위해서 Task_D는 Task_E 작업을 위해 필요한 정보를 조립하여 JSON 문서로 생성하는 것을 목표로하며 순수하게 기계적 작업이므로 python code로 작성되어야 한다. 

Task_D는 입력파일로
- claim_identification_view.json
- claims_identified_case_type.json
- claims_identified.json
- 청구취지작성규칙_Mapping_Table.md
- '청구취지작성규칙_{}.md / 여기서 {}은 case_kind 
- evidence_actio_support.json
- evidence_indexed.json
- fact_actio_support.json
- Fact_Ledger_base.json
들을 사용하며 출력파일은 
- 'C-XXX_claim_information.json' 형태다. 

Task_D에서 JSON 정보를 조립하는 상세한 작업 내용을 아래 <Details_of_Task_D>에 제시한다. 

<Details_of_Task_D>

## Sketch of 'JSON SCHEMA' of 'C-XXX_claim_information.json'
- 'claims_identified.json'의 C-XXX별 JSON Block이 basic building block
  - 아래 제시된 JSON 항목들 중 claim_id, claim_title, plaintiffs, defendants, claim_statement는 'claims_identified.json'의 C-XXX별 JSON Block에 존재하는 것들
- 그 외 나머지 JSON 항목들은 아래 제시된 Schema sketch에 설명 제공

<schema_sketch>
```
- claim_id
- claim_title
- plaintiffs
- defendants
- claim_statement
- case_kind / claim_id에 해당하는 claim_type 기입 (claim_type은 'claims_identified_case_type.json'에서 해당 claim_id가 존재하는 block에서 찾을 수 있음)
- "relief_summary_statement_rule" / 신규 생성, '청구취지작성규칙_Mapping_Table.md'에서 매칭된(동일한) case_kind에 해당하는 row에 대응하는 '청구취지작성규칙 파일' cell의 markdown 문서를 Default_Agent 폴더에서 찾아서 그 문서의 내용 전체를 기입
- source_fact_ids / F-XXX, F-XXX, ...
- fact_id_content / 신규 variable, source_fact_ids의 F-XXX별 정보들을 하나의 block으로 아래로 stack
  - Fact_Ledger_base.json에 존재하는 F-XXX별 json block(단, 'action'은 claim_identification_view.json의 해당 fact_id의 'fact_action_text'로 대체)
  - claim_identification_view.json의 해당 fact_id의 'juristic_act' json block
  - claim_identification_view.json의 해당 fact_id의 'party_roles' json block
  - claim_identification_view.json의 해당 fact_id의 'object_spec'~'property_transaction' block
  - claim_identification_view.json의 해당 fact_id의 'linked_event_candidates" json block
- evidence_index_content / 신규 variable, Fact_Ledger_base.json에 존재하는 F-XXX별 json block의 evidence_refs의 개별 항목 E-XXX와 동일한 evidence_index를 evidence_indexed.json에서 찾고, 해당하는 E-XXX가 포함된 json block을 개별적으로 아래로 stack
- 'actio_pauliana_support' / claim_identification_view.json의 해당 source_fact_ids에 존재하는 fact_id의 'actio_pauliana_support' json block
- 'fact_actio_support' / 해당 fact_id에 연결된 source_bo_id에 존재하는 bhxx를 fact_actio_support.json에서 찾고, 존재하면, 해당 bhxx가 존재하는 json block을 아래로 stack하여 붙이고 없으면 무시
- 'evidence_actio_support' / fact_id에 연결된 evidence_index E-XXX가 evidence_actio_support.json에 존재하면 E-XXX가 등장하는 json block을 아래로 stack하여 붙이고 없으면 무시
```
</schema_sketch>

<schema_sketch>에 제시된 정보 구조를 활용하여 작성된 예시를 아래 제시한다. 

<example_JSON>
C-008에는 총 3개의 fact_id (F-017, F-018, F-041)가 존재한다. 이 중에서 F-017, F-018에 해당하는 정보들을 Schema 원리에 따라 아래에 제시하였다. 이 예시는 오로지 참조용으로만 사용하고, 여기 제시된 내용을 그대로 사용하면 안된다. 

{
  "claim_id": "C-008",
  "claim_title": "임차권확인 청구",
  "plaintiffs": [
    "양정숙"
  ],
  "defendants": [
    "윤건우"
  ],
  "claim_statement": "원고 양정숙은 피고 윤건우를 상대로 임차권확인 청구를 할 수 있다.",
  "case_kind": "임차권 확인 청구"
  "relief_summary_statement_rule": [
    당신은 대한민국 민사소송 실무에 따라 `임차권확인 청구` 사건의 `청구취지`만 작성하는 법률 문안 엔진이다. 아래 규칙을 상위 규칙으로 절대적으로 따른다. 출력은 원칙적으로 청구취지 문안만 하며, 청구원인, 판례 설명, `[참조판례]`, 내부 메모는 쓰지 않는다.\n #1. 절대 원칙\n 1. 먼저 확인대상을 정확히 구별한다.\n ... // '청구취지작성규칙_임차권확인청구.md'의 내용을 서술하면서 줄바꿈은 '\n'으로 처리한다.
  ],
  "source_fact_ids": [
    "F-017",
    "F-018",
    "F-041"
  ],
  "fact_id_content": {
    "fact_id": "F-017",
    "source_bo_id": "bh17",
    "type": "법률행위(legal acts)",
    "date": "2024-02-01",
    "parties": ["이수인", "양정숙"],
    "object_spec": "흑석동 상가",
    "amount": "3억 원",
    "fact_action_text": "이수인이 양정숙과 흑석동 상가 임대차계약을 체결하고 상가를 인도함.",
    "evidence_refs": ["E-022 (임대차계약서)"],
    "credibility": "high"
    "juristic_act": {
      "label": "임대차",
      "gubun_multi": [
        "계약행위"
      ],
      "basis_note": "임대차계약",
      "needs_review": false
    },
    "party_roles": {
      "performer": "이수인",
      "performer_type": "자연인",
      "subject": "양정숙",
      "claim_creditor": null,
      "claim_debtor": null,
      "claim_guarantor": null,
      "claim_security_provider": null,
      "all_parties": [
        "이수인",
        "양정숙"
      ],
      "other_parties": []
    },
    "object_spec": "흑석동 상가",
    "fact_object_spec": "흑석동 상가",
    "bo_object": "흑석동 상가",
    "location": null,
    "method": null,
    "outcome": null,
    "amount": "3억 원",
    "amount_source_field": "fact.amount",
    "property_transaction": {
      "asset_id": null,
      "property_label_for_schedule": null,
      "transaction_type": null,
      "transaction_date": null,
      "registration_date": null,
      "registry_office": null,
      "registry_receipt_no": null,
      "registry_recorded_transfer_date": null,
      "market_value_at_act": null,
      "market_value_at_close": null,
      "sale_price": null,
      "consideration_breakdown": []
    },
    "linked_event_candidates": [
      {
        "evidence_index": "E-022",
        "candidate_id": "E-022-EC-01",
        "event_or_state": "event",
        "event_kind": "임대차",
        "event_subkind": null,
        "action_summary": "흑석동 상가 임대차 계약",
        "object_spec": null,
        "amount": "보증금 3억 원, 월 500만 원",
        "event_date": "2024-02-01",
        "identity_signature": "event|임대차|이수인|양정숙|보증금 3억 원|2024-02-01",
        "participants": {
          "actor_candidates": [
            "이수인"
          ],
          "counterparty_candidates": [
            "양정숙"
          ]
        },
        "current_state_candidate": {},
        "succession_candidate": {},
        "affected_asset_cluster_ids": [],
        "confidence": "high"
      }
    ],
    "evidence_index_content": {
      "evidence_index": "E-022",
      "doc_uid": "DOC-022-임대차계약서_이수인_양정숙",
      "title": "임대차계약서",
      "title_normalized": "임대차계약서",
      "doc_type": "처분문서",
      "key_facts": ["흑석동 상가 임대차"],
      "key_dates": ["2024-02-01", "2029-01-31"],
      "key_amounts": ["3억 원", "500만 원"],
      "key_parties": ["이수인", "양정숙"],
      "source_pointer": {"source": "evidence_all.json", "ordinal": 22},
      "doc_semantic_flags": ["claim_doc"],
      "property_cluster_id": "흑석동 상가"     
    },
    "actio_pauliana_support": null
  }, 
  "fact_id_content": {
    "fact_id": "F-018",
    "source_bo_id": "bh18",
    "type": "사실행위(factual acts)",
    "date": "2024-02-02",
    "parties": ["양정숙"],
    "object_spec": "흑석동 상가",
    "amount": null,
    "fact_action_text": "양정숙이 흑석동 상가에서 맛나식당을 운영함.",
    "evidence_refs": ["E-018 (사 업 자 등 록 증)"],
    "credibility": "high",
    "juristic_act": {
      "label": null,
      "gubun_multi": [],
      "basis_note": null,
      "needs_review": null
    },
    "party_roles": {
      "performer": "양정숙",
      "performer_type": "자연인",
      "subject": null,
      "claim_creditor": null,
      "claim_debtor": null,
      "claim_guarantor": null,
      "claim_security_provider": null,
      "all_parties": [
        "양정숙"
      ],
      "other_parties": []
    },
    "object_spec": "흑석동 상가",
    "fact_object_spec": "흑석동 상가",
    "bo_object": null,
    "location": null,
    "method": null,
    "outcome": null,
    "amount": null,
    "amount_source_field": null,
    "property_transaction": {
      "asset_id": null,
      "property_label_for_schedule": null,
      "transaction_type": null,
      "transaction_date": null,
      "registration_date": null,
      "registry_office": null,
      "registry_receipt_no": null,
      "registry_recorded_transfer_date": null,
      "market_value_at_act": null,
      "market_value_at_close": null,
      "sale_price": null,
      "consideration_breakdown": []
    },
    "linked_event_candidates": [
      {
        "evidence_index": "E-018",
        "candidate_id": "E-018-EC-01",
        "event_or_state": "state",
        "event_kind": "사업자등록",
        "event_subkind": null,
        "action_summary": "맛나식당 사업자 등록",
        "object_spec": null,
        "amount": null,
        "event_date": null,
        "identity_signature": "state|사업자등록|양정숙|맛나식당|2024-02-02",
        "participants": {
          "actor_candidates": [
          "양정숙"
          ]
        },
        "current_state_candidate": {
          "state_summary": "영업 중",
          "state_as_of": "2024-02-02",
          "current_user_candidates": [
            "양정숙"
          ]
        },
        "succession_candidate": {},
        "affected_asset_cluster_ids": [],
        "confidence": "high"
      }
    ],    
    "evidence_index_content": {
      "evidence_index": "E-018",
      "doc_uid": "DOC-018-사업자등록증_양정숙",
      "title": "사 업 자 등 록 증",
      "title_normalized": "사 업 자 등 록 증",
      "doc_type": "공문서",
      "key_facts": ["맛나식당 사업자 등록"],
      "key_dates": ["2024-02-01", "2024-02-02"],
      "key_amounts": [],
      "key_parties": ["양정숙"],
      "source_pointer": {"source": "evidence_all.json", "ordinal": 18},
      "doc_semantic_flags": ["status_doc"],
      "property_cluster_id": "흑석동 상가"
    },
    "actio_pauliana_support": null, 
  }, 
  "fact_id_content": {
    "fact_id": "F-041",
...
}
<example_JSON>


## File Location(주의)
Python code 작성 시 IO file들의 위치한 폴더 
<file_location>
- IN
  - claim_identification_view.json -- '/(Root)' 
  - claims_identified_case_type.json -- '/(Root)' 
  - claims_identified.json -- '/(Root)' 
  - 청구취지작성규칙_Mapping_Table.md -- '/Default_Agent' (현재 작업 폴더의 'other_files'폴더에서 찾을 수 있다)
  - '청구취지작성규칙_{}.md -- '/Default_Agent' / 여기서 {}은 case_kind 
  - evidence_actio_support.json -- '/(Root)' 
  - evidence_indexed.json -- '/(Root)' 
  - fact_actio_support.json -- '/(Root)' 
  - Fact_Ledger_base.json -- '/(Root)' 

- OUT
  - 'C-XXX_claim_information.json' -- '/(Root)' 
</file_location>

</Details_of_Task_D>

현재 개발 중인 agent의 'Python Code' 및 'Agent Script'의 기본적인 문법(syntax)을 작성하는 데 사용될 Skill 파일이 main folder('YAML_Combine')에 SKILL.md로 존재하므로 필요할 경우 이 문서를 참조하여 코드를 작성하라. 

그리고, claims_identified.json에서 식별된 청구권들은 다수이므로, 청구권별 json block들을 한 번에 생성하지 않고 Map-Reduce 기법을 사용하여 한 번에 최대 6개씩 병렬로 생성한다. 현재 다루는 사건의 경우, 식별된 청구권들이 총 13개이므로, '6개 > 6개 > 1개' 순서로 C-XXX_claim_information.json 파일들을 생성해야 한다. 

Map-reduce 기법은 'Stage_2_combined_old.yml'의 `- task_name: preD_assembly`, `- name: stage_claim_information_gen`에 제시된 기법을 표준자료로 삼아 작성하면 된다. 

지금까지 제시한 내용을 바탕으로 Stage 2의 Task_D 프롬프트를 작성하여 'Stage_2_Task_D.yaml'로 생성하라.


======================================================================================

## 답변

`Stage_2_Task_D.yaml`을 `2. Stage 2` 폴더에 생성했습니다. 이 파일은 `stage_claim_information_gen` 하나로 구성되어 있고, `map_reduce.max_concurrency: 6`으로 설정해 13개 청구권이 `6 > 6 > 1` 배치로 처리되도록 했습니다. 각 map item은 `preD_assembly` Python code-executor task가 맡아 `claims_identified.json` 등을 읽고, case_kind별 `청구취지작성규칙`을 찾아 `C-XXX_claim_information.json`을 루트에 생성합니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_Task_D.yaml†L1-L120】

조립 로직은 `fact_id_content` 내부에 fact별 상세 블록을 넣고, 동시에 `schema_sketch`에 맞춰 top-level의 `evidence_index_content`, `actio_pauliana_support`, `fact_actio_support`, `evidence_actio_support`도 함께 집계하도록 작성했습니다. `Default_Agent` 경로를 우선 사용하되 현재 작업 폴더의 `other_files`도 fallback으로 읽도록 해 두었습니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_Task_D.yaml†L383-L623】

검증으로는 Python code block compile 확인과 YAML parse 확인까지 마쳤습니다. 실제 MCP 백엔드에 붙여 실행까지는 하지 않았습니다.


==============================================================================================

## 질문

`2. Stage 2` 폴더를 기준으로 하라. 

`Stage_2_updated_A_B_C_v6.yml`을 실행하여 얻은 결과물들(from 'outputs' folder)을 사용하여 `Stage_2_Task_D.yaml`을 실행하여 개별 청구권(claim_id)에 대한 정보 블록 `C-XXX_claim_information.json`을 생성하여 `outputs_D` 폴더에 저장하였다. 

다음 작업은 Stage 2의 마지막 작업으로서 개별 청구권들에 대한 정보 문서 `C-XXX_claim_information.json`를 활용하여 각 청구권별 '청구취지' 및 '청구원인'을 작성하는 작업이다. 

예전에 작성된 Stage 2 전체 프롬프트인 `Stage_2_combined_old.yml`에서 **- name: stage_claim_description_gen** 이하 내용이 바로 이 작업에 해당한다. 

`Stage_2_combined_old.yml`의 **- name: stage_claim_description_gen** 이하는 아래의 작업들을 순차적으로 진행한다. 

1. map_reduce 지정
2. `- task_name: generate_module_block`에서 청구권(claim)에 대한 정보 블록(block) 생성
3. `- task_name: interpret_claim_metadata`에서 2번에서 생성된 정보 블록에 대한 메타 데이터 해석 생성(`C-###_claim_interpretation.json`를 개별 생성)
4. `- task_name: generate_description`에서 개별 청구권들에 대해 '청구취지'와 '청구원인'을 작성
5. `- task_name: save_description`에서 개별 청구권별로 생성된 청구취지 및 청구원인 작성 문서들을 json파일로 생성하고 저장
6. `- task_name: stage2_summary`에서 전체 map-reduce 작업을 완료 

`outpus_D`에 저장된 현재의 프롬프트 `Stage_2_updated_A_B_C_v6.yml`과 `Stage_2_Task_D.yaml`을 순차적으로 실행하여 생성된 `C-XXX_claim_information.json`의 세부 정보들을 기존 `Stage_2_combined_old.yml`의 **- name: stage_claim_description_gen** 이하가 제대로 활용하는지를 검증하고자 한다. 

기존 `Stage_2_combined_old.yml`의 **- name: stage_claim_description_gen**의 **2. `- task_name: generate_module_block`**이 `outpus_D`에 저장된 청구권(claim)에 대한 정보 블록(block) `C-XXX_claim_information.json`의 정보들을 모두 빠짐없이 잘 활용할 수 있는가? 그렇지 않다면 어떤 정보를 어떻게 더 활용하도록 **2. `- task_name: generate_module_block`** code를 수정해야 하는지, 그 개선방안을 최대한 자세하게 제시하라.

============================================================================================

## 답변

::code-comment{title="[P1] Current module classifier no longer matches the Task_D output schema" body="`determine_module_type()` still inspects only `claim_info[\"facts\"]` and `claim_info[\"evidences\"]`, but the current Task_D output stores the substantive payload under `fact_id_content` and `evidence_index_content`. With the new schema, this logic will usually see empty arrays and fall back to `calc_only`, so actio claims that contain both mortgage and transfer signals can be misclassified before `generate_module_block` even runs." file="/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml" start=3021 end=3042 priority=1 confidence=0.98}
::code-comment{title="[P1] stage_claim_description_gen is still reading the old claim file location" body="The old stage reads `C-###_claim_information.json` from the stage root, but your current workflow stores these files in `2. Stage 2/outputs_D/`. If this path mismatch is not fixed first, `generate_module_block` will not be consuming the current Task_D outputs at all." file="/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml" start=3051 end=3052 priority=1 confidence=0.99}
::code-comment{title="[P1] Relief drafting rule is explicitly removed before module generation" body="The current Task_D output includes a very large `relief_summary_statement_rule` block that contains remedy-structure constraints for actio claims, but `load_claim_info` removes it from `claim_info_str` and `generate_module_block` never receives it. That means the module generator is blind to rule-level signals about cancellation vs. restoration vs. value-compensation structure." file="/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml" start=3054 end=3068 priority=1 confidence=0.95}
::code-comment{title="[P2] generate_module_block gets a monolithic JSON blob with no field-usage contract" body="The prompt sends only `module_schemas_str` plus a single `claim_info_str` blob. With the new schema, crucial fields are buried inside `fact_id_content[*]` and top-level support bundles such as `actio_pauliana_support` / `fact_actio_support`. Because the prompt does not explicitly require the model to traverse and reconcile those structures, omission of juristic-act, party-role, property-transaction, and linked-event information becomes likely." file="/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml" start=3099 end=3115 priority=2 confidence=0.94}

결론부터 말하면, 현재 `Stage_2_combined_old.yml`의 `generate_module_block` 체인은 `outputs_D`의 현재 `C-XXX_claim_information.json`을 “모두 빠짐없이 잘 활용한다”고 보기 어렵습니다. 특히 사해행위취소 청구에서는 치명적인 누락이 있습니다. 새 산출물은 `fact_id_content`, `evidence_index_content`, `actio_pauliana_support`, `fact_actio_support`, `evidence_actio_support` 중심으로 짜여 있는데, old stage는 여전히 구 스키마의 `facts`/`evidences`를 기준으로 사고하고 있습니다. 실제 `C-007_claim_information.json`만 봐도 새 구조의 핵심 데이터가 `fact_id_content` 아래의 `juristic_act`, `party_roles`, `property_transaction`, `linked_event_candidates`, 그리고 fact별 actio support로 들어가 있습니다.【/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:20】【/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:38】【/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:46】【/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:66】【/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:80】【/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:163】【/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:208】

핵심 문제는 네 가지입니다.

1. `generate_module_block` 이전 단계가 이미 새 스키마를 놓칩니다. `determine_module_type()`가 `facts`와 `evidences`만 보므로, 현재 `outputs_D` 구조에서는 사해행위취소의 담보권형/소유권이전형 신호를 거의 못 잡습니다. 그래서 `C-007`처럼 `근저당`과 `소유권이전`이 같이 있는 케이스도 `calc_only`로 잘못 떨어질 위험이 큽니다. [Stage_2_combined_old.yml](/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom%20AI%20Partners/Legal%20POC%20portfolio/%E1%84%86%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A1%E1%84%8B%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%90%E1%85%B3-%E1%84%89%E1%85%A1%E1%84%92%E1%85%A2%E1%84%92%E1%85%A2%E1%86%BC%E1%84%8B%E1%85%B1%E1%84%8E%E1%85%B1%E1%84%89%E1%85%A9%E1%84%86%E1%85%B5%E1%86%BE%E1%84%83%E1%85%A2%E1%84%8B%E1%85%A7%E1%84%80%E1%85%B3%E1%86%B7%E1%84%8E%E1%85%A5%E1%86%BC%E1%84%80%E1%85%AE/POC%20-%20Law-aid%20Agent/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%B7%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3/prompt_updates_sequential/0.%20YAML_Updated/%E1%84%92%E1%85%AA%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%83%E1%85%AC%E1%86%AB%20YAML/YAML_Combine/2.%20Stage%202/Stage_2_combined_old.yml:3021)

2. 현재 workflow에서는 `C-XXX_claim_information.json`이 `outputs_D`에 저장되는데, old stage는 루트에서 읽습니다. 이 상태라면 `generate_module_block`는 현재 산출물을 “활용 못 하는” 수준이 아니라 아예 못 읽을 수 있습니다. [Stage_2_combined_old.yml](/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom%20AI%20Partners/Legal%20POC%20portfolio/%E1%84%86%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A1%E1%84%8B%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%90%E1%85%B3-%E1%84%89%E1%85%A1%E1%84%92%E1%85%A2%E1%84%92%E1%85%A2%E1%86%BC%E1%84%8B%E1%85%B1%E1%84%8E%E1%85%B1%E1%84%89%E1%85%A9%E1%84%86%E1%85%B5%E1%86%BE%E1%84%83%E1%85%A2%E1%84%8B%E1%85%A7%E1%84%80%E1%85%B3%E1%86%B7%E1%84%8E%E1%85%A5%E1%86%BC%E1%84%80%E1%85%AE/POC%20-%20Law-aid%20Agent/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%B7%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3/prompt_updates_sequential/0.%20YAML_Updated/%E1%84%92%E1%85%AA%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%83%E1%85%AC%E1%86%AB%20YAML/YAML_Combine/2.%20Stage%202/Stage_2_combined_old.yml:3051)

3. `relief_summary_statement_rule`이 module 생성 입력에서 빠집니다. 그런데 현재 `C-007`의 rule text에는 remedy mode, 말소/가액배상 분기, 담보권 있는 부동산 처리 원칙이 상세히 들어 있습니다. 이걸 빼고 module block을 만들면, 나중의 청구취지 구조와 어긋나는 module이 나올 수 있습니다. [Stage_2_combined_old.yml](/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom%20AI%20Partners/Legal%20POC%20portfolio/%E1%84%86%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A1%E1%84%8B%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%90%E1%85%B3-%E1%84%89%E1%85%A1%E1%84%92%E1%85%A2%E1%84%92%E1%85%A2%E1%86%BC%E1%84%8B%E1%85%B1%E1%84%8E%E1%85%B1%E1%84%89%E1%85%A9%E1%84%86%E1%85%B5%E1%86%BE%E1%84%83%E1%85%A2%E1%84%8B%E1%85%A7%E1%84%80%E1%85%B3%E1%86%B7%E1%84%8E%E1%85%A5%E1%86%BC%E1%84%80%E1%85%AE/POC%20-%20Law-aid%20Agent/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%B7%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3/prompt_updates_sequential/0.%20YAML_Updated/%E1%84%92%E1%85%AA%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%83%E1%85%AC%E1%86%AB%20YAML/YAML_Combine/2.%20Stage%202/Stage_2_combined_old.yml:3054) [C-007_claim_information.json](/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom%20AI%20Partners/Legal%20POC%20portfolio/%E1%84%86%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A1%E1%84%8B%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%90%E1%85%B3-%E1%84%89%E1%85%A1%E1%84%92%E1%85%A2%E1%84%92%E1%85%A2%E1%86%BC%E1%84%8B%E1%85%B1%E1%84%8E%E1%85%B1%E1%84%89%E1%85%A9%E1%84%86%E1%85%B5%E1%86%BE%E1%84%83%E1%85%A2%E1%84%8B%E1%85%A7%E1%84%80%E1%85%B3%E1%86%B7%E1%84%8E%E1%85%A5%E1%86%BC%E1%84%80%E1%85%AE/POC%20-%20Law-aid%20Agent/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%B7%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3/prompt_updates_sequential/0.%20YAML_Updated/%E1%84%92%E1%85%AA%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%83%E1%85%AC%E1%86%AB%20YAML/YAML_Combine/2.%20Stage%202/outputs_D/C-007_claim_information.json:12)

4. `generate_module_block`는 현재 raw JSON 전체를 한 덩어리로 넘길 뿐, “새 필드들을 반드시 어떻게 읽어라”라는 계약이 없습니다. 그래서 `juristic_act`, `party_roles`, `property_transaction`, `linked_event_candidates`, fact별 `actio_pauliana_support`, top-level `fact_actio_support` 같은 필드가 prompt 안에 있어도 LLM이 체계적으로 못 쓰는 구조입니다. [Stage_2_combined_old.yml](/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom%20AI%20Partners/Legal%20POC%20portfolio/%E1%84%86%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A1%E1%84%8B%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%90%E1%85%B3-%E1%84%89%E1%85%A1%E1%84%92%E1%85%A2%E1%84%92%E1%85%A2%E1%86%BC%E1%84%8B%E1%85%B1%E1%84%8E%E1%85%B1%E1%84%89%E1%85%A9%E1%84%86%E1%85%B5%E1%86%BE%E1%84%83%E1%85%A2%E1%84%8B%E1%85%A7%E1%84%80%E1%85%B3%E1%86%B7%E1%84%8E%E1%85%A5%E1%86%BC%E1%84%80%E1%85%AE/POC%20-%20Law-aid%20Agent/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%B7%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3/prompt_updates_sequential/0.%20YAML_Updated/%E1%84%92%E1%85%AA%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%83%E1%85%AC%E1%86%AB%20YAML/YAML_Combine/2.%20Stage%202/Stage_2_combined_old.yml:3099) [C-007_claim_information.json](/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom%20AI%20Partners/Legal%20POC%20portfolio/%E1%84%86%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A1%E1%84%8B%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%8C%E1%85%A5%E1%86%AB%E1%84%90%E1%85%B3-%E1%84%89%E1%85%A1%E1%84%92%E1%85%A2%E1%84%92%E1%85%A2%E1%86%BC%E1%84%8B%E1%85%B1%E1%84%8E%E1%85%B1%E1%84%89%E1%85%A9%E1%84%86%E1%85%B5%E1%86%BE%E1%84%83%E1%85%A2%E1%84%8B%E1%85%A7%E1%84%80%E1%85%B3%E1%86%B7%E1%84%8E%E1%85%A5%E1%86%BC%E1%84%80%E1%85%AE/POC%20-%20Law-aid%20Agent/%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%B7%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3/prompt_updates_sequential/0.%20YAML_Updated/%E1%84%92%E1%85%AA%E1%86%A8%E1%84%8C%E1%85%A5%E1%86%BC%E1%84%83%E1%85%AC%E1%86%AB%20YAML/YAML_Combine/2.%20Stage%202/outputs_D/C-007_claim_information.json:38)

개선은 `generate_module_block`만 만지면 충분하지 않고, 바로 앞 `load_claim_info`와 함께 바꾸는 것이 맞습니다. 최소 수정안은 아래 순서입니다.

1. 파일 경로를 `outputs_D/{claim_id}_claim_information.json`로 바꾸십시오.
2. `load_claim_info`에서 새 스키마를 old stage 친화형으로 정규화한 `module_input`을 만들고, 이걸 `generate_module_block`에 넘기십시오.
3. `relief_rule_str`를 `generate_module_block`에도 같이 넘기십시오.
4. `generate_module_block` prompt에 “반드시 사용해야 하는 필드 목록”을 명시하십시오.

추천하는 `load_claim_info` 출력 구조는 이런 형태입니다.

```python
claim_info = read_json(f"outputs_D/{claim_id}_claim_information.json")

fact_blocks = claim_info.get("fact_id_content", [])
evidence_blocks = claim_info.get("evidence_index_content", [])

module_input = {
    "claim_core": {
        "claim_id": claim_info.get("claim_id"),
        "claim_title": claim_info.get("claim_title"),
        "case_kind": claim_info.get("case_kind"),
        "plaintiffs": claim_info.get("plaintiffs", []),
        "defendants": claim_info.get("defendants", []),
        "claim_statement": claim_info.get("claim_statement"),
        "source_fact_ids": claim_info.get("source_fact_ids", []),
    },
    "fact_id_content": fact_blocks,
    "evidence_index_content": evidence_blocks,
    "actio_support_bundle": {
        "top_level_actio_pauliana_support": claim_info.get("actio_pauliana_support", []),
        "top_level_fact_actio_support": claim_info.get("fact_actio_support", []),
        "top_level_evidence_actio_support": claim_info.get("evidence_actio_support", []),
    },
    "compat_aliases": {
        "facts": fact_blocks,
        "evidences": evidence_blocks,
    },
}
```

`determine_module_type()`도 문자열 훑기보다 새 필드를 구조적으로 읽어야 합니다. 적어도 아래 신호는 반영해야 합니다.

```python
def determine_module_type(claim_info: dict) -> tuple[str, str]:
    facts = claim_info.get("fact_id_content", [])
    evidences = claim_info.get("evidence_index_content", [])
    actio_supports = (
        claim_info.get("actio_pauliana_support", [])
        + claim_info.get("fact_actio_support", [])
        + claim_info.get("evidence_actio_support", [])
    )

    full_text = json.dumps(facts, ensure_ascii=False) \
              + json.dumps(evidences, ensure_ascii=False) \
              + json.dumps(actio_supports, ensure_ascii=False)

    has_mortgage = any(
        kw in full_text for kw in ["근저당", "저당권", "근저당권설정", "근저당권"]
    )
    has_transfer = any(
        kw in full_text for kw in ["소유권이전", "이전등기", "매매", "양도"]
    )
    has_auction = any(
        kw in full_text for kw in ["경매", "배당", "배당금", "배당표"]
    )

    if has_mortgage and (has_transfer or has_auction):
        return "both", "mortgage_fraudulent_act_module_v1_mini.json, actio_pauliana_calc_v3_mini.json"
    if has_mortgage:
        return "mortgage_only", "mortgage_fraudulent_act_module_v1_mini.json"
    return "calc_only", "actio_pauliana_calc_v3_mini.json"
```

그리고 `generate_module_block` prompt는 이렇게 바꾸는 것이 좋습니다. 핵심은 “raw blob 하나”가 아니라 “섹션별 입력 + 사용 의무”입니다.

```yaml
- task_name: generate_module_block
  when: "prev.load_claim_info.is_actio == true"
  llm_provider: google
  llm_model: gemini-3.1-pro-preview
  prompts:
    - role: system
      content: |
        {{prev.load_claim_info.instruction_text}}

        추가 지시:
        - 반드시 아래 정보를 모두 검토하라.
        - `fact_id_content[*].juristic_act`, `party_roles`, `property_transaction`,
          `linked_event_candidates`, `actio_pauliana_support`,
          `fact_actio_support`, `evidence_actio_support`를 빠짐없이 반영하라.
        - preserved claim(피보전채권), fraudulent act(사해행위), recovery/remedy(원상회복 방식)
          를 구분해 모듈을 조립하라.
        - `relief_summary_statement_rule`의 remedy 관련 제약을 무시하지 말라.
        - JSON만 출력하라.

    - role: user
      content: |
        ## 모듈 JSON 스키마
        {{prev.load_claim_info.module_schemas_str}}

        ## 청구취지 작성 규칙
        {{prev.load_claim_info.relief_rule_str}}

        ## 정규화된 모듈 입력
        {{prev.load_claim_info.module_input_str}}

        ## 모듈 타입 결정 근거
        {{prev.load_claim_info.module_selection_basis_str}}
```

정리하면, 현재 old `generate_module_block`는 “입력 JSON이 들어오긴 하지만 새 스키마를 제대로 소비하도록 설계되어 있지 않다”가 정확한 판단입니다. 특히 사해행위취소 청구에서는 `fact_id_content` 중심의 새 구조와 `relief_summary_statement_rule`, support bundle을 명시적으로 읽도록 바꾸지 않으면 module block 품질이 흔들릴 가능성이 큽니다.

원하시면 다음 단계로 바로 이어서, 제가 `Stage_2_combined_old.yml`의 `stage_claim_description_gen` 중 `load_claim_info` + `generate_module_block`를 현재 `outputs_D` 스키마에 맞게 실제 수정안 형태로 재작성해드릴 수 있습니다.


===========================================================================================


## 질문

여기서 다음 작업으로 진행하기 전에 먼저 진행해야 할 것이 있다. 

`Stage_2_combined_old.yml`의 **- name: stage_claim_description_gen** 이하는 아래의 작업들 중 **1. map_reduce 지정** 작업과 **2. `- task_name: generate_module_block`에서 청구권(claim)에 대한 정보 블록(block) 생성** 작업 사이에 **- task_name: load_claim_info** 작업이 실제로 존재한다. 

`- task_name: load_claim_info` 작업 code를 분석하여 `outpus_D`에 저장된 `C-XXX_claim_information.json`의 세부 정보들을 빠짐없이 잘 불러오는지를 검증하라.  

# 주의: code에서 import하는 모든 파일들이 (code에 표시된) 폴더에 존재함을 가정하라.


============================================================================================

## 답변

**Findings**
1. [P1] `load_claim_info`는 현재 `outputs_D`가 아니라 stage root에서 `C-###_claim_information.json`를 읽습니다. 그래서 지금 workflow 기준으로는 아예 최신 Task_D 산출물을 못 읽을 수 있습니다. [Stage_2_combined_old.yml](</Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml:3051>) lines 3051-3052
2. [P1] 원본 JSON을 읽은 뒤 `relief_summary_statement_rule`를 의도적으로 제거합니다. 따라서 “세부 정보를 빠짐없이” downstream에 넘긴다고 보기는 어렵습니다. [Stage_2_combined_old.yml](</Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml:3054>) lines 3054-3068
3. [P1] `load_claim_info` 내부의 actio 분기용 `determine_module_type()`는 여전히 구 스키마의 `facts`/`evidences`만 봅니다. 새 산출물의 핵심 필드인 `fact_id_content`/`evidence_index_content`/support bundle은 로드되더라도 이 단계에서 실질적으로 활용되지 않습니다. [Stage_2_combined_old.yml](</Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml:3021>) lines 3021-3042

**판정**
원본 JSON을 “파싱해서 메모리에 읽는” 것만 보면, `load_claim_info`는 정상 경로만 맞다면 대부분의 상세 필드를 보존합니다. 실제 `outputs_D` 샘플을 확인해 보니 top-level에는 `fact_id_content`, `evidence_index_content`, `actio_pauliana_support`, `fact_actio_support`, `evidence_actio_support`가 있고, `fact_id_content[*]` 내부에는 `juristic_act`, `party_roles`, `property_transaction`, `linked_event_candidates`까지 들어 있습니다. [C-007_claim_information.json](</Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json:20>) lines 20-247

하지만 `load_claim_info`가 downstream에 넘기는 형태까지 포함해서 보면 “빠짐없이 잘 불러온다”는 평가는 어렵습니다. 현재 검증 결과는 이렇게 정리됩니다.

- `claim_info_without_rule`는 top-level에서 `relief_summary_statement_rule`만 제거하고 나머지는 그대로 둡니다.
- 따라서 `fact_id_content`, `evidence_index_content`, top-level support bundle 자체는 `claim_info_str` 안에 남습니다.
- 즉, nested detail이 추가로 잘려 나가지는 않습니다.
- 다만 `relief_summary_statement_rule`는 명시적으로 빠지고, 경로도 틀렸고, module type 판단은 새 스키마를 읽지 않습니다.

**결론**
좁게 보면:
- `read_json()` 이후의 객체 보존 자체는 대체로 괜찮습니다.
- `relief_summary_statement_rule`만 의도적으로 탈락합니다.

넓게 보면:
- 현재 `load_claim_info`는 `outputs_D` 기준 최신 `C-XXX_claim_information.json`을 end-to-end로 “빠짐없이 잘 불러온다”고 볼 수 없습니다.
- 이유는 `파일 위치 불일치 + 규칙 필드 제거 + 구 스키마 기반 분기 로직`입니다.

다음 단계로는 `generate_module_block`을 보기 전에 `load_claim_info`를 먼저 이렇게 고쳐야 합니다.
- 읽기 경로를 `outputs_D/{claim_id}_claim_information.json`로 변경
- `relief_summary_statement_rule`를 별도 보존하되 module generation에도 전달
- `determine_module_type()`가 `fact_id_content`, `evidence_index_content`, `fact_actio_support`, `evidence_actio_support`를 기준으로 판단하도록 수정

원하면 다음 답변에서 `load_claim_info` 코드만 대상으로, 현재 `outputs_D` 스키마에 맞춘 수정 버전을 바로 재작성해드리겠습니다.


==============================================================================================

## 질문

{claim_id}_claim_information.json이 모두 /(Root) 폴더에 있다고 가정하라. 즉, 실제로는 {claim_id}_claim_information.json이 로컬 폴더인 `outputs_D`에 존재하지만, 코드 작성 시에는 {claim_id}_claim_information.json이 모두 /(Root) 폴더에 있다고 가정해야 한다. 

이 가정 하에서 위에서 제시한 제안을 반영하여 load_claim_info 코드만 대상으로 현재 {claim_id}_claim_information.json의 스키마에 맞춘 수정 버전을 `Stage_2_combined_old.yml`의 해당 코드에 덮어 씌울 수 있도록 yaml 문법을 지켜서 작성하여 `2. Stage 2` 폴더에 `Stage_2_1_load_claim_info.yaml`로 생성하라.

=============================================================================================

## 답변

`load_claim_info` 교체용 YAML snippet을 `2. Stage 2/Stage_2_1_load_claim_info.yaml`로 생성했습니다. 이 버전은 사용자 지시대로 `{claim_id}_claim_information.json`이 모두 `/(Root)`에 있다고 가정하고 읽으며, 현재 스키마의 `fact_id_content`, `evidence_index_content`, `actio_pauliana_support`, `fact_actio_support`, `evidence_actio_support`를 기준으로 정규화 입력과 신호 추출을 수행합니다. 또 `relief_summary_statement_rule`를 더 이상 버리지 않고 `claim_info_str` 안에도 유지하며, backward compatibility를 위해 기존 출력 키(`claim_info_str`, `relief_rule_str`, `instruction_text`, `module_schemas_str`, `module_type_key`)는 그대로 남겼습니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L1-L471】

검증으로는 이 snippet 파일의 YAML parse와 embedded Python code compile까지 확인했습니다. 핵심 수정 구간은 새 스키마 기반 신호 추출/모듈 타입 판정 부분과, root 경로 가정 하의 로드 및 enriched output 조립 부분입니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L305-L378】【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L412-L467】


==============================================================================================

## 질문

이제 위에서 생성한 'Stage_2_1_load_claim_info.yaml'이 실행되었다는 것을 전제로 하라. 

이 전제 하에서 위에서 다루었던 아래 작업을 재수행하라. 
---
`Stage_2_updated_A_B_C_v6.yml`을 실행하여 얻은 결과물들(from 'outputs' folder)을 사용하여 `Stage_2_Task_D.yaml`을 실행하여 개별 청구권(claim_id)에 대한 정보 블록 `C-XXX_claim_information.json`을 생성하여 `outputs_D` 폴더에 저장하였다. 

다음 작업은 Stage 2의 마지막 작업으로서 개별 청구권들에 대한 정보 문서 `C-XXX_claim_information.json`를 활용하여 각 청구권별 '청구취지' 및 '청구원인'을 작성하는 작업이다. 

예전에 작성된 Stage 2 전체 프롬프트인 `Stage_2_combined_old.yml`에서 **- name: stage_claim_description_gen** 이하 내용이 바로 이 작업에 해당한다. 

`Stage_2_combined_old.yml`의 **- name: stage_claim_description_gen** 이하는 아래의 작업들을 순차적으로 진행한다. 

1. map_reduce 지정
2. `- task_name: generate_module_block`에서 청구권(claim)에 대한 정보 블록(block) 생성
3. `- task_name: interpret_claim_metadata`에서 2번에서 생성된 정보 블록에 대한 메타 데이터 해석 생성(`C-###_claim_interpretation.json`를 개별 생성)
4. `- task_name: generate_description`에서 개별 청구권들에 대해 '청구취지'와 '청구원인'을 작성
5. `- task_name: save_description`에서 개별 청구권별로 생성된 청구취지 및 청구원인 작성 문서들을 json파일로 생성하고 저장
6. `- task_name: stage2_summary`에서 전체 map-reduce 작업을 완료 

`outpus_D`에 저장된 현재의 프롬프트 `Stage_2_updated_A_B_C_v6.yml`과 `Stage_2_Task_D.yaml`을 순차적으로 실행하여 생성된 `C-XXX_claim_information.json`의 세부 정보들을 기존 `Stage_2_combined_old.yml`의 **- name: stage_claim_description_gen** 이하가 제대로 활용하는지를 검증하고자 한다. 

기존 `Stage_2_combined_old.yml`의 **- name: stage_claim_description_gen**의 **2. `- task_name: generate_module_block`**이 `outpus_D`에 저장된 청구권(claim)에 대한 정보 블록(block) `C-XXX_claim_information.json`의 정보들을 모두 빠짐없이 잘 활용할 수 있는가? 그렇지 않다면 어떤 정보를 어떻게 더 활용하도록 **2. `- task_name: generate_module_block`** code를 수정해야 하는지, 그 개선방안을 최대한 자세하게 제시하라.

============================================================================================

## 답변

현재 전제에서는 이전의 두 문제는 해소된 것으로 봐도 됩니다. `load_claim_info`가 root의 `{claim_id}_claim_information.json`을 읽는다는 가정이므로 경로 문제는 사라지고, 새 `load_claim_info`는 `relief_rule_str`, `claim_info_str`, `module_input_str`, `module_selection_basis_str`를 모두 준비해 둡니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사에이전트-사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L381-L465】 하지만 그 전제하에서도 `generate_module_block`이 현재 `C-XXX_claim_information.json`의 정보를 “모두 빠짐없이 잘 활용한다”고 보기는 어렵습니다. 핵심 이유는 아주 단순합니다. `generate_module_block`는 여전히 `instruction_text`, `module_schemas_str`, `claim_info_str`만 받고, 새로 준비된 가장 구조화된 입력인 `module_input_str`와 `module_selection_basis_str`를 전혀 쓰지 않기 때문입니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml†L3099-L3115】

남아 있는 실질 문제는 네 가지입니다.

1. `generate_module_block`는 `module_input_str`를 안 씁니다. 그런데 새 `load_claim_info`는 이미 `claim_core`, `fact_id_content`, `evidence_index_content`, `actio_support_bundle`, `derived_signals`로 정규화된 입력을 만들어 둡니다. 이게 가장 중요한 입력인데 지금 prompt에는 안 들어갑니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L381-L409】【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml†L3107-L3115】

2. `module_selection_basis_str`를 안 씁니다. 새 `load_claim_info`는 `has_mortgage_signal`, `has_transfer_signal`, `has_auction_signal`, `claim_snapshots`, `property_candidates`, `evidence_indexes`까지 뽑아 module 선택 근거를 명시적으로 제공합니다. 그런데 `generate_module_block`는 왜 `both`인지, 왜 `mortgage_only`인지 그 사유를 못 보고 바로 생성에 들어갑니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L305-L378】【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L431-L465】

3. 필드 사용 계약이 없습니다. 실제 `C-007_claim_information.json`에는 `fact_id_content[*]` 안에 `juristic_act`, `party_roles`, `property_transaction`, `linked_event_candidates`, `evidence_index_content`, `actio_pauliana_support`, `fact_actio_support`, `evidence_actio_support`가 풍부하게 들어 있습니다. 그런데 prompt는 “이 청구 정보로 JSON module을 생성하라”까지만 말하고, 어떤 필드를 어떤 법적 요소에 써야 하는지 지시하지 않습니다. 그래서 preserved claim, fraudulent act, beneficiary, target property, remedy-mode 관련 정보가 누락될 위험이 큽니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/outputs_D/C-007_claim_information.json†L20-L247】【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_combined_old.yml†L3107-L3115】

4. 규칙은 살아났지만 여전히 저평가됩니다. 지금은 `claim_info_str` 안에 `relief_summary_statement_rule`가 보존돼 있지만, 별도 섹션으로 강조되지 않으니 큰 JSON blob에 묻힐 수 있습니다. 사해행위취소에서 취소/원상회복/가액배상 분기는 module block 설계의 상위 제약이라 별도 입력으로 드러내는 편이 안전합니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L421-L438】

따라서 판정은 이렇습니다.  
`Stage_2_1_load_claim_info.yaml`을 전제로 하면 `generate_module_block`는 예전보다 훨씬 많은 정보를 “접근 가능”한 상태로 받습니다. 하지만 여전히 현재 `C-XXX_claim_information.json`의 정보를 “모두 빠짐없이 잘 활용한다”고 보기는 어렵습니다. 문제는 정보 부족이 아니라, 정보를 구조적으로 소비하도록 prompt가 설계되어 있지 않다는 점입니다.

가장 좋은 수정은 `generate_module_block`를 아래처럼 바꾸는 것입니다.

```yaml
- task_name: generate_module_block
  when: "prev.load_claim_info.is_actio == true"
  llm_provider: google
  llm_model: gemini-3.1-pro-preview
  prompts:
    - role: system
      content: |
        {{prev.load_claim_info.instruction_text}}

        추가 지시:
        - 출력은 반드시 module schema에 정확히 맞는 순수 JSON만 반환한다.
        - 아래 우선순위로 입력을 사용한다.
          1. module_selection_basis_str
          2. module_input_str
          3. claim_info_str
          4. relief_rule_str
        - `fact_id_content[*]`의 `juristic_act`, `party_roles`, `property_transaction`,
          `linked_event_candidates`를 모두 검토하라.
        - `actio_support_bundle.actio_pauliana_support`,
          `actio_support_bundle.fact_actio_support`,
          `actio_support_bundle.evidence_actio_support`를 모두 검토하라.
        - preserved claim, fraudulent act, beneficiary/transferee, target property,
          remedy/recovery structure를 서로 분리해서 식별한 뒤 schema에 매핑하라.
        - top-level 정보와 fact별 nested 정보가 중복되면 버리지 말고 상호 보강하라.
        - 증거 인덱스, source_bo_id, fact_id의 연결관계를 유지하라.

    - role: user
      content: |
        ## 모듈 JSON 스키마
        {{prev.load_claim_info.module_schemas_str}}

        ## 모듈 선택 근거
        {{prev.load_claim_info.module_selection_basis_str}}

        ## 청구취지 작성 규칙
        {{prev.load_claim_info.relief_rule_str}}

        ## 정규화된 모듈 입력
        {{prev.load_claim_info.module_input_str}}

        ## 원본 청구 정보
        {{prev.load_claim_info.claim_info_str}}

        아래 조건을 모두 만족하여 module JSON을 생성하라.
        1. `claim_core`에서 사건의 기본 식별정보를 추출할 것
        2. `fact_id_content[*]`에서 피보전채권 사실, 사해행위 사실, 등기/배당/처분 구조를 나눠 추출할 것
        3. `evidence_index_content[*]`에서 각 사실을 직접 뒷받침하는 문서와 날짜/금액/당사자를 반영할 것
        4. `actio_support_bundle`에서 plaintiff claim snapshot, target property, beneficiary candidate,
           fraudulent act date candidate를 우선적으로 반영할 것
        5. `relief_rule_str`의 remedy 구조와 충돌하지 않도록 module을 설계할 것
        6. 누락 가능한 필드가 아니라면 빈칸으로 두지 말고 입력에서 찾아 채울 것
        7. 마크다운 없이 순수 JSON만 반환할 것
```

이 수정이 중요한 이유는 세 가지입니다.

1. `module_input_str`를 주 입력으로 삼으면 `fact_id_content`와 support bundle을 분리된 구조로 읽게 되어, 현재 스키마를 제대로 소비할 수 있습니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L381-L409】

2. `module_selection_basis_str`를 같이 주면 왜 `both` 또는 `mortgage_only`인지가 고정되어, model이 schema는 두 개 받았지만 실제로는 하나만 채우는 식의 흔들림을 줄일 수 있습니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L347-L378】【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L447-L465】

3. `relief_rule_str`를 별도 섹션으로 주면, module 생성 단계부터 remedy mode를 rule-aware하게 잡을 수 있습니다. 이건 뒤의 `interpret_claim_metadata`와 `generate_description` 품질에도 직접 연결됩니다.【F:/Users/hogyujhang/Library/CloudStorage/Dropbox/Business/Eroom AI Partners/Legal POC portfolio/민사해행위취소및대여금청구/POC - Law-aid Agent/프롬프트/prompt_updates_sequential/0. YAML_Updated/확정된 YAML/YAML_Combine/2. Stage 2/Stage_2_1_load_claim_info.yaml†L431-L438】

한 줄로 정리하면, 지금 단계의 남은 병목은 `load_claim_info`가 아니라 `generate_module_block` prompt 설계입니다.  
정보는 이제 충분히 들어오고 있고, 다음 수정은 “어떤 정보를 어떤 우선순위로 반드시 읽어라”를 명시하는 쪽으로 가야 합니다.

원하면 다음 단계로 바로 이어서, 제가 위 개선안을 반영한 `generate_module_block` 교체용 YAML snippet도 같은 방식으로 별도 파일로 만들어드릴 수 있습니다.


==============================================================================================










